2025Q2PLAN {curinginnos}

이번 분기(4월 ~ 6월)는 대대적인 백엔드 안정화 및 리팩터링, 로깅시스템 도입, 이벤트 기반 아키텍처 도입, DB 마이그레이션 작업을 주도하기 전에 앞서 핵심하위도메인을 재설계하는 시간을 갖는다. 2025WEEK10END에서도 말했지만, 일년의 한 분기는 다음 세 분기의 폭발적인 스프린트를 위한 재정비의 시간이라고도 했다. 그것이 올해의 제2분기가 될 것이고, 그 기간동안에 서비스팀의 문화를 새로 쓰게 될 것이다.

• Logging
  • AWS CloudWatch 로깅전략세우기 feat. NestJS
  • Sentry 도입하여 예외, 에러, 이슈 로깅
• Domain Driven Design
  • Service Architecture Recommendations
  • Flexible Reservation System Refactoring with DDD {deprecated}
  • ddd로 바라본 큐링이노스 {curinginnos}
  • 휴무일, 공휴일, 월대관 등등을 정책으로 관리하기 {curinginnos}
  • 핵심 하위도메인 (Payment, Ticket 등) 식별
  • 바운디드 컨텍스트 (모듈, 의존성 경계) 설계
  • 이벤트 스토밍 진행 w/ 서비스팀 + 대표
  • 이벤트 기반 아키텍처 도입
    • 이벤트 소싱 패턴 도입
    • CQRS (Command Query Responsibility Segregation) 도입
• Database
  • Wall of Tables: SQL 마이그레이션을 위한 DB 테이블 간 관계 최적화 {curinginnos} 및 전체 Entity Relationship Diagram 그려 벽에 붙히기
  • Prisma를 버리고 TypeORM 또는 Drizzle 같은 ORM으로 갈아타야 할 이유가 생겼다. → 이건 좀 더 생각해봐야 할 문제가 되었다. prisma가 버전업이 되면서 기존의 Rust 엔진이 직접 조인하던 걸 쿼리문으로 바꿨기 때문에 SQL에서의 성능향상이 이루어졌기 때문이다. 그럼에도 불구하고 쿼리문을 미리 뽑아볼 수 없다면 과감히 Prisma를 버려야 한다. 예측불가능한 코드에 의존할 수는 없는터.
  • Mongodb to SQL Migration 플랜 PostgreSQL 쪽으로 선호도가 기울고 있다. 가장 큰 건 Json 타입으로, 값객체를 별도의 테이블이 아닌 자체의 컬럼으로 관리할 수 있을 뿐더러, JSON 프로퍼티를 쿼리하는 문법도 존재하기 때문에 --물론 이 방법은 아마도 raw query를 써야겠지만-- 마이그레이션에 상당한 이점을 가져갈 것으로 보인다. 냅다 마이그레이션을 할 수는 없는게, MongoDB의 ObjectID를 어떻게 PK 필드로 전환할 수 있을지와 릴레이션이 끊어진 테이블 간의 관계도를 재구축하여야 한다.
  • Postgresql 서비스 선택전략
• API
  • dto 최적화. 불필요한 연관 엔티티를 리스폰스 에서 제외시키고 id 필드로 대체. bounded context 설계도에 따른 리소스 요쳥 api 분리
  • Pagination 최적화 및 일관성 확보